Filed under: BDD, Cucumber, Executable specification, — Tags: Behaviour-Driven Development, Gherkin — Thomas Sundberg — 2018-04-17
BDD is the acronym for Behaviour-Driven Development. It is a way to describe the behaviour of a system and a way to make sure that it is developed to behave as it should.
BDD is used for understanding what to create and for verifying the result.
But BDD could also be the acronym for Business-Driven Development. BDDers work really hard to bridge the communication gap between development and business. We really try to involve the business people in the development. We value their input and love discussing concrete examples describing what the system should do. How it is done is less important when understanding what really matters for the business. Focusing on the what and not the how is a differentiator between communicative developers and regular developers.
(more...)Filed under: Cucumber, Executable specification, Presentation, Selenium, — Tags: Behaviour-Driven Development, Gherkin, The four rules of simple design — Thomas Sundberg — 2018-03-26
In April I will be talking at Testing stage in Kiev, Ukraine
I have two sessions:
They are connected in the sense that they are both about how to implement the support code you need for your test automation initiative. As a developer, I know that how you implement code is really important. It is ultimately a matter of maintainability. And maintainability is probably the most important property a piece of code can have after being correct. Code that can't be maintained will create problems for you during the entire lifetime of your product.
(more...)Filed under: BDD, Cucumber, Executable specification, — Tags: Behaviour-Driven Development, Gherkin, Scenarios — Thomas Sundberg — 2017-05-29
Are there any global properties that a Gherkin scenario should fulfill? A short answer is, no.
A longer answer is that there are some properties that are good and probably useful in many different contexts.
(more...)Filed under: BDD, Cucumber, Executable specification, Requirements, — Tags: Behaviour-Driven Development, Gherkin, Good specifications — Thomas Sundberg — 2017-02-26
A good specification is
An interesting question is "How do you create a good specification?" There are obviously a lot of different ways to end up with a good specification. You may be lucky and randomly end up with something good. There are, however, better ways than to rely on luck.
(more...)Filed under: BDD, Cucumber, Executable specification, Requirements, — Tags: Behaviour-Driven Development, Gherkin, Good specifications — Thomas Sundberg — 2017-01-30
What makes one specification a bad specification and another specification a good specification? What is the fundamental difference between two specifications?
(more...)Filed under: BDD, Cucumber, Executable specification, — Tags: Behaviour-Driven Development, Gherkin — Thomas Sundberg — 2016-12-04
Sometimes I see questions asking for flexibility in Gherkin, the language used by Cucumber. The purpose is often to remove duplication. An example may be this Stackoverflow question
Removing duplication is often a very a good thing. It is, however, sometimes better to keep duplication and gain clarity and readability.
(more...)Filed under: Cucumber, Executable specification, Test automation, — Tags: Automated acceptance criteria, Automated acceptance tests, Collaboration, Concrete examples, Cucumber-jvm, JUnit, Readability, Requirements — Thomas Sundberg — 2014-03-30
Before I can try to motivate why you should use a tool, let me define what it is and what it does.
Cucumber is a tool for collaboration and testing. It is used to create examples of behaviour that are executable. Creating examples in a collaborative way emphasize close cooperation between business analysts, testers and developers. The examples they come up with can be used as acceptance tests for the system being developed. It can be used as a testing tool where the tests are defined in a business friendly language while still being executable.
Our goal is to create a common understanding of the problem and therefore simplify the communication between all parties involved. We would also like to get something that is possible to use for automating the verification of the resulting program. That is, use as a base for test automation of the system.
(more...)
RSS